Rules shouldn't be installed to /etc/udev but to /usr/lib/udev. If you want to change the rule priority, change its prefix (like 10 or 20).

@kamack38 thanks for the feedback. Code is updated according to it.
I went for 55 priority because it loads after critical system rules (50-54) but before conflicting package rules like i2c-tools (60+). Hopefully this should provide sufficient precedence to fix Fedora's I2C issue without risking interference with core device initialization

@s-badran Please do not include *.code-workspace, put it into your global .gitignore config instead because IDE or editor rules are user-specific and should be there.

@s-badran Do you have concrete or theoretical experience about a situation when this directory is missing? Which distribution? I mean sudo mkdir -p $INSTALL_UDEV_DIR_PATH/rules.d.

@s-badran Was changed udev rule tested? And permissions exception handling? Btw. I refactored the master branch to using from periphery import I2C instead of smbus2 so your branch has to be rebased.

@s-badran Do you have concrete or theoretical experience about a situation when this directory is missing? Which distribution? I mean sudo mkdir -p $INSTALL_UDEV_DIR_PATH/rules.d.

Honestly, I don't have a reproducible Fedora instance where /usr/lib/udev/rules.d was completely missing, but I have seen minimal/container images and some custom installs where rules.d wasn't present or writable.
mkdir -p it ensures the target directory exists before tee writes the rule and prevents the installer from failing on systems that omit that subdir.

@s-badran Was changed udev rule tested? And permissions exception handling? Btw. I refactored the master branch to using from periphery import I2C instead of smbus2 so your branch has to be rebased.

I tested the rule locally on Ubuntu 24.04 ; installed the rule (as 55-...), reloaded rules with udevadm control --reload-rules && udevadm trigger, and verified /dev/i2c-* showed root:i2c and 0660 as expected. I couldn't test directly on Fedora 43 due to lack of access. (I believe the approach should work on Fedora too, which is why I asked the issue creator to test the branch first)

I added explicit PermissionError handling inside numberpad.py for the initial bus-open and for the runtime send function so we log a clear, actionable error (suggestingi2cgroup membership, re-login/reboot, or udev rule reload). That makes diagnosis much clearer in the logs if a user still sees issues.

I will rebase fix-i2c-permission-issue on top of master and port the SMBus calls to periphery.I2C so the branch applies cleanly.

I figured I better have someone to test the fix on a fedora 43 OS, before submitting this PR.